Emergency 9-1-1 portal and application

ABSTRACT

A computer aided prioritization (CAP) system may receive, from the emergency event reporter device, an emergency event including a priority selected from a set of event priorities and a type of event selected from a set of event types associated with the selected event priority; determine, based on the emergency event and without querying the emergency event reporter device for additional information, whether the emergency event indicates a higher priority emergency event to be handled by a computer aided dispatch (CAD) system or a lower priority emergency event to be handled automatically by a computer aided event module (CAEM); and selectively route the emergency event report to at least one of the CAD system and the CAEM according to the determination.

BACKGROUND

In current caller to emergency dispatch systems (e.g., 9-1-1 dispatch),a dispatcher may ask a multitude of questions to the caller and recordthe answers. These questions may be directed to determining the caller'sname, emergency and location based on the answers given by the caller.Only after collecting all of the necessary information can thedispatcher locate an appropriate nearest first responder to bedispatched to the location of the caller.

One potential cause for slow response time is an inability of thedispatcher to understand the caller. In the best case scenario, thecaller is calling from the home address on a clear line with nobackground noise, and the first responder may be dispatched immediately.In most cases, the caller is somewhere other than their home address,calling from a noisy location, has trouble articulating his or heremergency and location, and the dispatcher has to somehow figure out whoto send and where.

Lack of communication arising from language barriers, poor reception ora panic stricken caller who cannot speak or is screaming contributes todelays in response time. In some instances, these issues may cause acomplete inability for the dispatcher to dispense a first responderaltogether. In domestic violence cases or instances when a caller cannotspeak, the situation may become even more desperate because thedispatcher cannot communicate with the caller, and unless an accurateaddress or global positioning system (GPS) coordinate is established, nofirst responder can be dispatched.

With the advent of functionality related to Phase II of the FederalCommunications Commissions' E-911 initiative, a location of a caller maybe determined by either triangulating the location based on multiplecellular phone towers; or in the case of a smartphone, by way of anexact GPS location determined by the smartphone device. This technologyhas improved response time, but in some cases several re-bids (i.e.,requests for a location) are needed to obtain a useful caller location.In the case of triangulation in metropolitan areas, such locationinformation is rarely accurate enough to locate a caller without his orher assistance.

One way for emergency dispatch systems to associate additionalinformation with an emergency caller is by way of an automatic numberidentification (ANI)/automatic location identification (ALI) database.The ANI is a database of information configured to store nameinformation and location information associated with telephone lines ortelephone numbers. The ANI/ALI database may be used by emergencydispatch to retrieve the physical address and name associated with thetelephone line from which a 9-1-1 call originated. This information maynot be available for mobile phones that are designated as 9-1-1 onlywith no mobile plans, or throw away/disposable mobile phones. Also, suchinformation may not be particularly useful to emergency dispatch systemsfor voice over internet protocol (VoIP) phones or mobile phones, as suchdevices may be utilized at a location far removed from the physicallocation on file in the ANI/ALI database. Moreover, the ANI/ALI databaseprovides only limited information about the caller.

As a result, current emergency dispatch systems are fraught with delays,and in some cases, fail altogether because of communication or technicalissues.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates an exemplary emergency event including an eventtype, an event priority, and event details.

FIG. 1B illustrates an exemplary system for implementing an emergencyportal and dispatch system configured to handle emergency events.

FIG. 2A illustrates an exemplary data flow that may be performed by anemergency portal and dispatch system environment utilizing existingANI/ALI functionality and configured to handle emergency events.

FIG. 2B illustrates an exemplary data flow that may be performed by anemergency portal and dispatch system environment utilizing IP technologyand configured to handle emergency events.

FIG. 3 illustrates an exemplary user interface of an emergency prioritydispatch application for selecting a priority for an emergency event.

FIG. 4 illustrates an exemplary user interface of an emergency prioritydispatch application in night mode.

FIG. 5 illustrates an exemplary user interface of an emergency prioritydispatch application for selecting an event type of a high priorityemergency event.

FIG. 6 illustrates an exemplary user interface of an emergency prioritydispatch application for selecting an event type of a medium priorityemergency event.

FIG. 7 illustrates an exemplary user interface of an emergency prioritydispatch application for selecting an event type of a low priorityemergency event.

FIG. 8 illustrates an exemplary user interface of an emergency prioritydispatch application for selecting an event type of a third-partypriority emergency event.

FIG. 9 illustrates an exemplary user interface of an emergency prioritydispatch application for selecting an event type of an anonymouspriority emergency event.

FIG. 10 illustrates an exemplary user interface of an emergency prioritydispatch application for communicating information with emergencydispatch.

FIG. 11 illustrates an exemplary user interface of a computer aidedprioritization system.

FIG. 12 illustrates an exemplary process for receiving and processing anemergency event according to an identified event priority and type.

DETAILED DESCRIPTION

An emergency portal and dispatch system may improve thecaller-to-emergency dispatch interaction by prioritizing incoming calls,providing additional caller information and creating a unified interfaceto bridge external emergency data with a computer aided dispatch (CAD)system at an emergency dispatch center. The emergency portal anddispatch system performs these objectives by shifting some of theresponsibility onto the caller, business or reporting third-party toelectronically provide a priority of the call, a type of emergency, andother pertinent information to the dispatch center so that the emergencydispatcher may dispatch an appropriate first responder in the fastestand most efficient manner possible.

With the emergency priority dispatch architecture, a caller may providea priority and a type of emergency to dispatch as part of an emergencyrequest or during the establishment of the emergency call, without theneed to obtain additional queries for additional information from thedispatch center. This allows the dispatch center to automaticallyprioritize calls before an emergency dispatcher/call-taker getsinvolved. Instead of asking probing questions and waiting for answers,the dispatcher/call-taker may become more proactive with the caller byverifying the electronically received information and dispatching theproper first responder in the most expeditious manner. Moreover, theemergency portal may allow low priority, third party and anonymousemergency requests to be processed without any emergency dispatcherinvolvement.

The emergency priority dispatch may include an emergency prioritydispatch (EPD) application executed by a user's communications device. Auser may launch the emergency priority dispatch application to beginreporting an emergency. The user may further select a type of connectionicon to identify a type of communications session to have with dispatch,such as voice, texting or text-to-speech/speech-to-text. Selecting oneof the communications options may trigger a request or may begin callinitiation with dispatch. In some cases, the initial request to dispatchmay include the priority and type of emergency information. In othercases while waiting for the connection to be established, which in thecurrent centralized automatic message accounting (CAMA) environment maytake from 5 to 10 seconds, the emergency priority dispatch applicationmay prompt the caller for one or more of a priority and a type ofemergency. If the caller selects a pre-defined type of emergency, theapplication may execute additional processes that are designed to helpemergency dispatch more quickly dispatch the correct and closest firstresponder. These processes may include, for example, asking the callerquestions designed to receive a simple yes/no response, or to asking thecaller to select from a limited set options that clearly explain thetype of information being requested.

While the caller is communicating with the emergency dispatcher,additional caller emergency information may be transmitted by theemergency priority dispatch application to dispatch. At applicationsetup time, the caller may enter caller emergency information and set apermission level to determine what caller emergency information may betransmitted with what priority and type of emergency.

The emergency priority dispatch user interface may further assist thecaller in texting and text-to-speech modes by providing short-cuts tocommon phrases used in emergency conversations that may be selected bythe caller without the need to type in using a keyboard These commonphrases may be most helpful in the texting mode because they may clearlyexplain the emergency and avoid abbreviations that may be ambiguous.

Before or after a first responder is dispatched, the emergency dispatchmay retrieve the additional caller emergency information from theemergency priority dispatch application and forward it to the firstresponder. Or, the additional caller information may be retrieved from acaller information server. Once the first responder arrives at a callerlocation, and in cases when an emergency dispatcher cannot relayadditional caller data information electronically to the firstresponder, the first responder may be able to retrieve information fromthe EPD application directly. This also enhances the ability of thefirst responder to assist the caller, especially in a medical emergencyif the caller becomes unavailable, such as after fainting or going intoshock. The emergency portal and dispatch system may further providepertinent personal, medical, handicap and location information to anemergency dispatcher, in order to expedite dispatching of appropriatefirst responders.

For third-party products that provide incident information, theemergency portal and dispatch system may provide a unified interfacethat allows prioritization and categorization of dispatch requests withthe additional ability of providing and aggregating alarm location,contact information, telematics data, video feeds, pre-plans, photos andother relevant data to minimize emergency dispatcher involvement andcutting the time to dispatch the appropriate first responders.

While the emergency portal and dispatch system is discussed herein inrelation to 9-1-1 service as implemented in the United States andCanada, the system is not so limited and is equally applicable toworldwide portal and caller-to-emergency dispatch connectivity andincluding, for example, 1-1-2 service available in Euro-Zone countries.

As a portion of shifting responsibility from dispatch to the caller, anemergency portal and dispatch system may define an event format for useby the dispatch system. FIG. 1A illustrates an exemplary emergency event102, including an event priority 104, an event type 106, and optionally,additional event details 108. This event format may be used to allowemergency dispatch to quickly identify and classify incoming emergencyevents 102.

The event priority 104 included in the emergency event 102 may include apriority selected from a set of event priorities. The set of eventpriorities may include one or more of: a high priority event indicativeof a life-threatening event requiring urgent assistance, a mediumpriority event indicative of a non-life threatening event requiringurgent assistance, a low priority event indicative of a non-lifethreatening event not requiring urgent assistance, a third partypriority event indicative of a report of information where a user of theemergency event reporter device is not involved, and an anonymous eventpriority indicative of a report of information where the user of theemergency event reporter device is not involved and wishes to remainanonymous.

The event type 106 included in the emergency event 102 may include atype of event selected from a set of event types associated with theselected event priority 104. The set of event types may include one ormore of: medical, accident, fire, child abduction, missing person,domestic violence, assault, robbery, hit & run, storm/property damage,vandalism, loud noise, gang activity, shots fired, riot, burglary, rape,stolen vehicle, stolen property, suspicious persons/activity, suspiciousvehicle, observed drug deal, prostitution, among other exemplary typesof emergency.

The emergency event 102 may further include additional event details108, such as any other information associated with the emergency event102 that may be useful for dispatch to have. Moreover, the additionalevent details 108 may be supplemented by additional reporters ofinformation to provide additional relevant information to dispatch.

FIG. 1B illustrates an exemplary system 100 for implementing anemergency portal and dispatch system configured to handle emergencyevents 102. As shown, the system 100 includes a public safety answeringpoint (PSAP) 110 in communication with a computer-aided dispatch (CAD)system 112 which is in turn in communication with caller prioritydispatch (CPD) workstations 114. The PSAP 110 may further be incommunication with a plurality of reporters of information over acommunications network 120. These reporters of information may include asmartphone 116 having an emergency priority dispatch (EPD) application118, a phone device 122, a burglar alarm 124, a fire alarm 126, a caralarm 128, a medical alert device 130, a telematics unit 132, and avideo feed 134. In some instances, the system 100 may include an ANI/ALIsystem 136. The system 100 may further include an automatic callerinformation (ACI) database 138 in communication with an ACI server 140.The ACI server 140 may further provide an emergency caller information(ECI) web portal 142. The system may also include a computer aidedprioritization (CAP) system 144 in communication with the PSAP 110, acomputer aided event module (CAEM) 146, the CAD system 112, and the CPDworkstation 114. System 100 may take many different forms and includemultiple and/or alternate components and facilities. While an exemplarysystem 100 is shown in FIG. 1B, the exemplary components illustrated inFIG. 1B are not intended to be limiting. For example, some examples areimplemented without ANI/ALI systems 136. Indeed, additional oralternative components and/or implementations may be used.

As illustrated in FIG. 1B, system 100 may include a PSAP 110. The PSAP110 may include one or more devices responsible for receiving andhandling emergency events 102, such as requests for emergency servicessuch as police, medical and fire. In some cases a PSAP 110 may beassociated with a particular geographic area such that requests foremergency services may be routed to the appropriate PSAP 110 for thearea. The PSAP 110 may include call distribution functionality, such asfunctionality configured to route the requests to the CAD system 112.

The CAD system 112 may be configured to receive the emergency events 102and to selectively forward the emergency events 102 to CPD workstations114. The CPD workstation 114 may be computing devices used by dispatcherpersonnel to receive and interact with callers and emergency event 102information. The CAD system 112 may further be configured to maintainthe status of responding resources in the field (e.g., ambulancelocations) as well as the status of the various dispatch/call-takeroperators and CPD workstations 114. In many cases, the CAD system 112may be located in a relatively centralized public-safety call center,while in other cases portions of the CAD system 112, such CPDworkstations 114, may be located with mobile field personnel.

The smartphone 116 may be implemented as a combination of hardware andsoftware, and may include one or more software applications or processesfor causing one or more computer processors to perform the operations ofthe smartphone 116 described herein. Smartphones 116 may include anycellular or mobile phone that are programmable, and includes, but is notlimited to phones running the iOS operating systems distributed by AppleInc. of Cupertino, Calif., the BlackBerry OS distributed by Research InMotion of Waterloo, Canada, the Android operating system developed bythe Open Handset Alliance, and Microsoft Windows® operating systemdeveloped by Microsoft Inc. of Redmond, Wash.

One such application installed on the smartphone 116 may be the EPDapplication 118. The smartphone 116 may be configured to execute the EPDapplication 118 to perform operations in relation to emergency dispatch,such as providing emergency events 102 to the PSAP 110. Further aspectsof the EPD application 118 are discussed in detail below with respect toFIGS. 3-10.

The communications network 120 may provide communications services, suchas packet-switched network services (e.g., Internet access and/or VoIPcommunication services) and/or circuit-switched services (e.g., plainold telephone service (POTS) and/or integrated services digital network(ISDN) services) to various communications devices. Communicationdevices include, but are not limited to smartphones 116 or other phonedevices 122 such as cell phones, VoIP phones, and public switchedtelephone network (PSTN) phones configured to communicate over the POTS.Communications devices may also include tablet computers, laptopcomputers, desktop computers or any device other that may provide acommunication session over a connection between the PSAP 110 and one ormore of a caller, a business, and a third-party emergency productprovider.

The communications network 120 may include any combination of wired orwireless forms of communication. For example, the communications network120 may include cable, optical fibers, cellular towers, etc. In somecases, the communications network 120 may support the use of the CAMAtelephone protocol for emergency requests sent to the PSAP 110 such asemergency 9-1-1 calls. Other communication protocols that may beutilized over the communications network 120 may include, but are notlimited to, dial-up networking, teletype data transmission, internetprotocol (IP) and short message service (SMS)/multimedia messagingservice (MMS) messaging, among others.

When utilizing a phone device 122 that lacks an ability to provideemergency events 102, such as a voice-only plain old telephone systemtelephone, the system 100 may provide compatibility by allowing adispatcher/call-taker utilizing a CPD workstation 114 to manually enterthe event priority 104 and emergency type 106 to facilitate entry of theemergency event 102 into the system 100.

In addition to smartphones 116 and phone devices 122, additionalreporters may provide information to dispatch. For example, burglaralarms 124 may provide information regarding break-ins at buildinglocations, fire alarms 126 may provide information regarding fires atbuilding locations, car alarms 128 may provide information regardingauto thefts or break-ins, medical alert device 130 may provideinformation regarding health emergencies of monitored users, telematicsunit 132 may provide information regarding vehicle crashes and history,and video feeds 134 may provide video information relating to past orin-progress incidents. To facilitate the handling of emergencies, theseadditional reporters of information may provide emergency events 102including event priority 104, event type 106, and optionally furtherevent details 108.

In some examples, an ANI/ALI system 136 may be included in the system100 as a reporter of supplemental information for received emergencyevents 102. For example, the ANI/ALI system 136 may be configured toaccept requests for physical address and name information associatedwith a phone number, perform queries of an ANI/ALI database for therequested information, and respond to the requests by returning therequested name and physical location on file in the ANI/ALI database.

The ACI database 138 may further be included in the system 100 as anadditional reporter of supplemental information, and may be configuredto store additional information regarding users of the PSAP 110.Initially (or at least prior to the reporting of an emergency), a usermay pre-register to have certain predetermined information available tothe PSAP 110. For example, the predetermined information may includepersonal information, location information, medical information,physical/mental handicap information, special needs information,language information, special circumstances information, and emergencycontact information, as some examples. Moreover, the user may identifypredetermined information as being releasable based on the event type106 of the emergency. For example, medical information may only bereleased to the PSAP 110 for medical emergencies of the user, andnext-of-kin information may only be released upon death.

Personal information may include, but is not limited to: name, phonenumber, age, sex, race, height, weight, eye color, hair color,date-of-birth, photo, primary/secondary language, and e-mail address.Location information may include, but is not limited to: physicaladdress, latitude/longitude of address, type of address, type ofstructure, photo of structure, number of stories, type of utilities,alarms, video cameras, nearest fire hydrant, gated community, nearestcross streets and/or land marks. Medical information may include, but isnot limited to: blood type, medical conditions such as diabetes, HIV,food or drug allergies, prior heart attack or any other relevant medicalconditions; primary-care physician name, phone number, pager number,e-mail address and preferred hospital. Special-needs and mental/physicalhandicap information may include, but is not limited to: hearingimpaired, visually impaired, mentally impaired, loss of limbs, eyesight, special needs child, physically impaired or young child. Languageinformation may include, but is not limited to: a primary/nationallanguage of the system 100, an indication of a secondary language of thesystem 100, a primary language of a caller, a secondary language of acaller and a flag that indicates whether or not the caller is able tocommunicate in the primary language of the primary/national language ofthe system 100. Special circumstances information may include, but isnot limited to: dog on premises, confined to bed, confined to wheelchair, elderly person living alone or any other special circumstancesthat would help the first responder in an emergency situation. Emergencycontact information may include, but is not limited to: name, address,phone number, relationship to caller and e-mail address, in whatcircumstance the emergency contacts will be notified, and what method ofnotification will be used (e.g., text-to-speech, phone call, SMS TextMessage or e-mail).

The ACI server 140 may be configured to receive requests for thepredetermined information from dispatch, and may selectively retrieveand provide the predetermined information responsive to the requests.The ACI server 140 may further support an ECI web portal 142 configuredto allow the users to add, edit, remove, and otherwise update thepredetermined information and conditions for its release. The ECI webportal 142 may provide secure access to allow callers to add or editstored caller information including, but not limited to: personal,medical, handicap and mental information, as well as location, contact,vehicle and system information. A caller may use the ECI web portal 142to enter or change their information as well as information regardingtheir family members including, but not limited to, spouse, significantother, child, parent, other relative, or acquaintance. Other than theauthorized callers, access to the stored caller information may behighly secure and limited to personnell with the security clearances. Insome cases, a high security firewall may be used to protect theintegrity of the data and to ensure its distribution only to authorizedPSAP 110 locations.

The CAP system 144 may be configured to receive an emergency event 102including an event priority 104 selected from a set of event priorities104 and an event type 106 selected from a set of event types 106associated with the selected event priority 104. The CAP system 144 mayfurther be configured to determine, based on the emergency event 102,whether the emergency event 102 indicates a higher priority emergencyevent 102 to be handled by a dispatcher/call-taker (e.g., by the CADsystem 112) or a lower priority emergency event 102 to be handledautomatically (e.g., by the CAEM 146 discussed in more detail below).This determination may be made by the CAP system 144 without queryingthe emergency event reporter device for additional information. Based onthe determination, the CAP system 144 may further be configured toselectively route the higher-priority emergency event 102 reports to theCAD system 112 and the lower-priority event reports to the CAEM 146.

The CAEM 146 may be configured to automatically handle lower-priorityemergency event 102. For example, the CAEM 146 may be configured toreturn a message to the user indicating that the emergency event 102 wasreceived and will be processed. The CAEM 146 may also be configured torequest additional information from the reporter of the emergency event102. As some examples, the CAEM 146 may be configured to providepre-formatted phrases to the caller that are designed to receive asimple yes/no response, or to ask the caller to select from a limitedset of options that clearly explain the type of information beingrequested.

The CAP system 144 may be further configured to supplement informationincluded in the emergency event 102 according to a predetermined rulefor including additional information. As some examples, thepredetermined rule for including additional information in the emergencyevent 102 may include one or more of: (i) a rule making pre-enteredemergency information available based on at least one of the selectedevent priority 104 and the event type 106 of the emergency event 102;(ii) a rule including telematics data in emergency event 102 reports forevents including a vehicle; (iii) a rule including health information inemergency event 102 reports for events requiring medical attention; (iv)a rule including additional contact information in the emergency event102 reports for events requiring notification of emergency contacts; (v)a rule including floor-plan information for emergency event 102 reportsrequiring access to a building; (vi) a rule including picture or videoinformation for emergency event 102 reports for which picture or videoinformation is available; and (vii) a rule including vehicle informationfor emergency events 102 that involve vehicles. If the conditions of oneor more of these rules are triggered based on the fields of theemergency event 102, the CAP system 144 may be configured to retrievethe additional information from one or more of the ANI/ALI system 136and the ACI server 140.

Moreover, additional reporters may provide information to dispatch. Theunified third-party interface 148 of the CAP system 144 may beconfigured to receive such information in a uniform manner. For example,one or more of the burglar alarms 124, fire alarms 126, car alarms 128,medical alert device 130, telematics units 132, and video feeds 134 mayprovide information to the CAEM 146 for the predetermined rules by wayof the unified third-party interface 148 of the CAP system 144.Exemplary supplemental information to be received via the third-partyinterface 148 may include: type of alarm or emergency, emergencycontacts, business name, business location, hazardous materialinformation, sprinkler information, telematics, video feeds, photos,architectural drawings, pre-plans/evacuation information, etc. and anyother information that will enable the emergency dispatcher to expeditedispatching the appropriate first responders. Moreover, the third-partyinterface 148 may also be configured to receive emergency events 102from various event reporters, the received emergency events 102including an event priority 104 and an event type 106, similar to asdiscussed above with respect to caller-reported incidents.

The CAP system 144 may further be configured to present the selectedevent priority 104, event type 106, event details 108 and any additionalsupplemental information to a dispatcher/call-taker associated with theCAD system 112 before, or while a communications session is establishedbetween a dispatcher/call-taker of the CAD system 112 and the reportingdevice (e.g., the smartphone 116 executing the EPD application 118).

As a more specific example, the CAP system 144 may be configured toreceive an emergency event 102 from a smartphone 116 executed an EPDapplication 118. The EPD application 118 may connect to the CAP system144 utilizing a data connection and may provide a unique identifierassociated with the network device (e.g. phone number, serial numberetc.) to the CAP system 144. The EPD application 118 may substantiallysimultaneously connect to the PSAP 110 utilizing a voice and/or dataconnection (depending on the capabilities of the PSAP 110), and may passthe unique networked computing device identifier from the PSAP 110 tothe CAP system 144. The unique networked computing device identifierpassed by the PSAP 110 to the CAP system 144 may then be associated withthe networked computing device identifier passed to the CAP system 144directly, in order to allow the CAP system 144 to make a positiveidentification of the event reporter. Once a positive identification hasbeen made, the CAP system 144 may be configured to transmit theemergency event 102 and appropriate personal, medical, physical/mentalhandicap, contact, location and vehicle information to the CPDworkstation 114 or to the CAEM 146 for processing.

With respect to the reporting of emergency events 102 by third-partyevent reporters, such as burglar alarms 124, fire alarms 126, car alarms128, medical alert devices 130, telematics units 132 and video feeds134, a communications session may be established with the CAP system 144over which an emergency event 102 may be provided. The emergency event102 may include information such as a unique identifier associated withthe third party device (e.g. serial number, account number etc.), anevent priority 104 and an emergency type 106. The CAP system 144 may beconfigured to route the emergency event 102 along with any additionalevent details 108 (e.g., location, contact, pre-plan, video, personal,medical, physical/mental handicap, or vehicle information) to theappropriate CPD workstation 114 or to the CAEM 146 for processing.

FIG. 2A illustrates an exemplary data flow 200-A that may be performedby an emergency portal and dispatch system 100 environment utilizingexisting ANI/ALI functionality and configured to handle emergency events102. The data flow 200-A may be performed by various devices, such as bythe CAP system 144 in communication with an ANI/ALI system 136 and oneor more event reporters over a communications network 120. The exemplarydata flow 200-A may be performed in systems 100 in which ACIfunctionality is integrated into an existing PSAP 110 system utilizingANI/ALI information.

The exemplary data flow 200-A may begin with an emergency event 102being generated by an event reporter. Exemplary event reporters mayinclude any of the reporters discussed above, such as a smartphone 116executing an EPD application 118, a phone device 122, a burglar alarm124, a fire alarm 126, a car alarm 128, a medical alert device 130, atelematics unit 132, or a video feed 134. The emergency event 102 mayinclude an event priority 104 and an event type 106, as discussed above.

The CAP system 144 may receive the emergency event 102 from the eventreporter. In some examples, the emergency event 102 may be received bythe CAP system 144 over the communications network 120 via the PSAP 110.In other examples, the emergency event 102 may be received by the CAPsystem 144 via a third-party interface 148.

Upon receipt of the event, the CAP system 144 may be configured torequest ANI/ALI information from the ANI/ALI system 136 according to thereceived emergency event 102. For example, based on an identifierincluded in the emergency event 102 such as a phone number of thecaller, the CAP system 144 may request the ANI/ALI system 136 to queryan ANI/ALI database for the physical address and name associated withthe caller from which the emergency event originated. The CAP system 144may further be configured to receive the requested ANI/ALI information.For example, responsive to the request, the ANI/ALI system 136 mayprovide the requested information, and may return the requested name andphysical location on file in the ANI/ALI database. The CAP system 144may be configured to supplement the information of the emergency event102 according to the received ANI/ALI information. This additionalinformation may be incorporated into the emergency event 102 asadditional event details 108.

The CAP system 144 may be further configured to supplement theinformation of the emergency event 102 according to a predetermined rulekeyed to at least a portion of the information received from the ANI/ALIsystem 136 and additional information in the emergency event 102. As anexample, the CAP system 144 may identify based on the event type 106 ofthe emergency event 102 that the emergency event 102 indicates a medicalemergency for an identified user. Accordingly, the CAP system 144 mayinvoke a rule making pre-entered emergency information for the useravailable based on at least one of the selected event priority 104 andthe event type 106 of the emergency event 102. The pre-entered emergencyinformation may have been previously entered by the user by way of theECI web portal 142.

Continuing with the medical emergency event 102 example, the CAP system144 may request certain predetermined medical information from the ACIdatabase 138 that is intended to be provided to the CAD system 112 inthe case of a medical emergency. The ACI database 138 may respond to therequest with the requested information. The CAP system 144 may thenincorporate the supplemental information into the emergency event 102 asadditional event details 108, and may forward the supplemented emergencyevent 102 to the CAD system 112 for further processing (or to the CAEM146 for a lower-priority emergency event 102).

FIG. 2B illustrates an exemplary data flow 200-B that may be performedby an emergency portal and dispatch system 100 environment utilizing IPtechnology and configured to handle emergency events 102. Similar to theexemplary data flow 200-A, the exemplary data flow 200-B may also beperformed by various devices, such as by the CAP system 144 incommunication with one or more event reporters over a communicationsnetwork 120.

Similar to the exemplary data flow 200-A, the exemplary data flow 200-Bmay begin with an emergency event 102 being generated by an eventreporter. Upon receipt of the emergency event 102, the CAP system 144may be configured to determine whether any ACI information related tothe emergency event 102 was received. For example, an emergency event102 may be received from a smartphone 116 executing an EPD application118, where the event requires supplementation according to anyapplicable rules. In other examples, an emergency event 102 may bereceived where the EPD application 118 has already supplemented theemergency event 102 with locally-stored additional event details 108. Insuch an instance, further supplementation of the emergency event 102 maybe unnecessary. In some examples, regardless of whether the emergencyevent 102 was supplemented by the reporting event reporter, the CAPsystem 144 may determine to supplement the event according to the ACIdatabase 138.

If the CAP system 144 determines to supplement the information of theemergency event 102, may be configured to supplement informationincluded in the emergency event 102 according to a predetermined rulefor including additional information based on the information of theemergency event 102 directly, without requiring the use of an ANI/ALIsystem.

For instance, the CAP system 144 may query the ACI database 138 forinformation based on one or more of an identifier of the callerassociated with the emergency event 102 (e.g., an IP address from whichthe emergency event was received 102, a caller name, login ID, or otherhandle included in the emergency event 102, etc.), an event priority 104of the event, and an event type 106 of the event. The ACI database 138may provide the requested information back to the CAP system 144, andthe CAP system 144 may incorporate the supplemental information into theemergency event 102 as additional event details 108. The CAP system 144may then forward the supplemented emergency event 102 to the CAD system112 for further processing (or to the CAEM 146 for a lower-priorityemergency event 102).

FIG. 3 illustrates an exemplary user interface 302 of an EPD application118 for selecting an event priority 104 for an emergency event 102. Theuser interface 302 may be provided, for example, by a smartphone 116executing the EPD application 118.

As illustrated, the user interface 302 may include priority controls 304configured to allow a user to select a relevant event priority 104. Theuser interface 302 may accordingly receive a user selection of the eventpriority 104 upon a user selection of one of the priority controls 304.For example, the user interface 302 may include priority controls 304for the selection of high priority, medium priority, low priority,third-party report priority, and anonymous priority event priorities104.

A high priority event priority 104 may identify a life-threatening eventneeding an immediate response. Exemplary high priority event types 106may include medical emergencies, immediate physical dangers such asdomestic violence, fires or any other life threatening event.

A medium priority event priority 104 may identify a non-life threateningeven still requiring a fast response. Exemplary medium priority eventtypes 106 may include hit & run, vandalism, an accident with no obviousinjuries, a storm/property damage with no obvious injuries, an unarmedrobbery in progress, etc.

A low event priority 104 may identify a non-life threatening event notrequiring an immediate response. Exemplary low priority event types 106may include filing a police report after the fact for a burglary not inprogress, a minor accident, minor storm or property damage, vandalism,stolen vehicle or property, etc.

A third-party event priority 104 may identify an event where the calleris not physically involved, but wants dispatch to be aware of thesituation. Exemplary third-party event types 106 may include thereporting of a car accident where the caller is not physically involved,the reporting of a suspicious person/activity or vehicle, the reportingof a drug dealer or deal in progress, or the reporting of prostitutionor shooting in an area.

An anonymous event priority 104 is similar to a third-party eventpriority 104, except the identity of the reporter may be keptconfidential from dispatch. The anonymous option encourages callers toreport suspicious activity without the fear of being found out. This maybe a useful priority 104 in certain situations, such as for children inschool who see event types 106 such as bullying, illegal activity suchas consuming alcohol or selling drugs, or for any person who wants toreport a crime or other illegal activity without identifying themselves.This information may then be distributed to neighborhood watch groups aswell as to law enforcement.

The user interface 302 may also include a bypass control 306 configuredto allow the user to connect with dispatch directly without specifyingthe event priority 104, a home control 308 configured to allow the userto return to a home page of the EPD application 118, a day/night control310 configured to toggle the background of the EPD application 118 forbetter day or night visibility.

Texting communication may be established between the EPD application 118and dispatch upon selection of a texting control 312 from the EPDapplication 118. More specifically, the EPD application 118 may beconfigured to cause the smartphone 116 to send and receive text messageswith the CAP system 144. The CAP system 144 in turn may pass the textmessages between the smartphone 116 and a CPD workstation 114 of adispatcher communicating with the user of the EPD application 118.Accordingly, the text messages may be displayed to thedispatcher/call-taker. In some cases, the dispatcher/call-taker mayfurther utilize pre-formatted messages, such as questions designed toreceive a simple yes/no response, or asking the caller to select from alimited set of options that clearly explain the type of informationbeing requested. These pre-formatted messages may be set up through theCAP system 144 and stored on the ACI server 140 or in the ACI database138.

Voice communication may be established between the EPD application 118and dispatch upon selection of a voice control 314 from the EPDapplication 118. To facilities the voice communication, the PSAP 110 mayreceive a voice call initiated by the EPD application 118 of thesmartphone 116. The PSAP 110 may accordingly route the received voicecall to an appropriate dispatcher/call taker or CPD workstation 114. Invoice mode, the CPD workstation 114 may be used by thedispatcher/call-taker to enter an event priority 104 and an event type106 to be passed to the CAP system 144.

FIG. 4 illustrates an exemplary user interface 402 of an EPD application118 in night mode. The user interface 402 may be displayed, for example,upon selecting the day/night control 310 configured to toggle thebackground of the EPD application 118. The user interface 402 in thisinstance may be an exemplary night mode version of the user interface302 discussed above. The night mode may display the same information asthe day mode, but may do so with a dark background rather than a lightbackground. The dark background may be more readable in a darkenvironment, and may also allow a user to report an emergency event 102without throwing a large amount of light and being spotted.

FIG. 5 illustrates an exemplary user interface 502 of an EPD application118 for selecting an event type 106 of a high priority emergency event102. Similar to the user interface 302, the user interface 502 mayinclude a home control 308 configured to allow the user to return to ahome page of the EPD application 118, a day/night control 310 configuredto toggle the background of the EPD application 118 for better day ornight visibility, a texting control 312 configured to access textingfunctionality, and a voice control 314 configured to access voicefunctionality.

Moreover, similar to the user interface 402, the user interface 502 mayalso include priority controls 304 for the selection of high priority,medium priority, low priority, third-party report priority, andanonymous priority emergency events 102. In the illustrated example, ahigh priority event type 106 was selected (e.g., from the user interface302). The user interface 502 may further include an indication that thehigh priority event type 106 was selected, for example, by highlightingthe priority control 304 associated with a high priority event type 106.

Additionally, the user interface 502 may include type controls 504 forthe selection of different event types 106 of emergency events 102. Theavailable event types 106 may be those event types 106 associated withthe selected event priority 104. For example, upon receiving a selectionof a high priority event priority 104, the user interface 502 mayprovide type controls 504 for a set of high priority event types 106,such as a medical emergency, an accident, a fire, a child abduction, amissing person, a domestic violence incident, an assault, a robbery, andanother emergency to be specified by a user. The user interface 502 maybe configured to allow a user to select the type control 504 associatedwith the event type 106 for the emergency event 102 being reported.

Upon selection of the event priority 104 and event type 106 (andpotentially after receiving a user confirmation) the EPD application 118may cause the smartphone 116 to submit the emergency event 102 to theCAP system 144.

FIG. 6 illustrates an exemplary user interface 602 of an EPD application118 for selecting an event type 106 of a medium priority emergency event102. For example, upon receiving a selection of a medium priority eventpriority 104, the user interface 602 may provide type controls 504 for aset of medium priority event types 106, such as a hit & run accident, anaccident, a storm or property damage, vandalism, a loud noise complaint,gang/shots fired/riots, an assault, a robbery, or another emergency tobe specified by a user. The user interface 602 may be configured toallow a user to select the type control 504 associated with the eventtype 106 for the emergency event 102 being reported.

FIG. 7 illustrates an exemplary user interface 702 of an EPD application118 for selecting an event type 106 of a low priority emergency event102. For example, upon receiving a selection of a low priority eventpriority 104, the user interface 702 may provide type controls 504 for aset of low priority event types 106, such as a burglary after the fact,an accident after the fact, a storm or property damage, a rape orassault after the fact, vandalism after the fact, a previous incident ofdomestic violence, a stolen vehicle, stolen property, or another type ofreport of an incident after the fact. The user interface 702 may beconfigured to allow a user to select the type control 504 associatedwith the event type 106 for the emergency event 102 being reported.

FIG. 8 illustrates an exemplary user interface 802 of an EPD application118 for selecting an event type 106 of a third-party priority emergencyevent 102. For example, upon receiving a selection of a third partyevent priority 104, the user interface 802 may provide type controls 504for a set of third-party priority event types 106, such as a report of asuspicions person, a report of a suspicious vehicle, a report of aprobable drug dealer, a report of an accident in which the third-partyis not involved, a report of an assault in which the third-party is notinvolved, a report of probably prostitution, a report of a robbery inwhich the third-party is not involved, a report of a fire observed bythe third-party, and a report of probable gang or riot activity. Theuser interface 802 may be configured to allow a user to select the typecontrol 504 associated with the event type 106 for the emergency event102 being reported.

FIG. 9 illustrates an exemplary user interface 902 of an EPD application118 for selecting an event type 106 of an anonymous priority emergencyevent 102. The user interface 902 may include similar options to thosefor the third-party priority emergency event 102, except that theidentity of the reporter may be kept confidential for an anonymouspriority event type 106.

FIG. 10 illustrates an exemplary user interface 1002 of an EPDapplication 118 for communicating information with emergency dispatch.The user interface 1002 may be provided by the EPD application 118 uponproviding an emergency event 102 based on a selection of an eventpriority 104 and an event type 106. The user interface 1002 may includesummary information 1004 relating to the emergency event 102 and callerinformation 1006 related to the caller reporting the emergency event.

The user interface 1002 may further allow for the display of dialog 1008between the EPD application 118 and dispatch related to the emergencyevent 102 being reported. An exemplary dialog 1008 is illustrated in theuser interface 1002, including updates from dispatch to the EPDapplication 118 indicating the status of dispatch in responding to theemergency event 102 being reported.

In some cases, the EPD application 118, CAP system 144 and CPDworkstation 114 may establish a texting environment that allows thedispatcher/call-taker to communicate with the caller. This environmentmay be displayed in the dialog 1008 portion of the user interface 1002.The texting environment may provide pre-formatted phrases by way of thedialog 1008 portion of the user interface 1002 that are designed toreceive a simple yes/no response, or to ask the caller to select fromoptions that clearly explain the type of information needed in order todispatch a first responder. The EPD application 118 may further providecontrols in the user interface 1002 to allow for the reception ofresponses from the caller, such as yes and no buttons to receive yes orno responses, or option controls in response to multiple choicequestions from dispatch. These provided controls may allow for thecaller to respond to questions from dispatch while minimizingkeystrokes. The dialogue between the dispatcher/call-taker and thecaller may be electronically transferred to the CAD system 112 and maybe associated with the emergency event 102.

FIG. 11 illustrates an exemplary user interface 1102 of a CAP system144. The user interface 1102 of the CAP system 144 may include beconfigured to present a listing of the emergency events 102 beinghandled by the CAP system 144. The user interface 1102 of the CAP system144 may be configured to show the status of external connections orcommunications session with event reporters, which may include, but arenot limited to, smartphones 116 having an EPD application 118, phonedevices 122, burglar alarms 124, fire alarms 126, car alarms 128,medical alert devices 130, telematics units 132, and video feeds 134.Each communications session may be displayed on the user interface 1102until its status is changed to completed by a dispatcher/call-taker. Insome examples, the status of connections being handled by the CAEM 146may automatically be set to complete by the CAEM 146 upon completion ofhandling the connection. Changing the status to complete may cause theconnection to be dropped from the display.

For example, the user interface 1102 of the CAP system 144 may beconfigured to display pertinent information such as the event priority104 of the emergency events 102, the event type 106 of the emergencyevents 102, and the event details 108 of the emergency event 102.

The user interface 1102 of the CAP system 144 may be further configuredto display additional information related to the handling of the event,such as a time at which the emergency event 102 was received, an elapsedtime the caller has been connected, a status indicative of whether thecall has been handled and, if so, how (e.g., whether the caller iscurrently on hold or is communication with dispatch according to voiceor text messaging), and whether the emergency event 102 is being handledby a dispatcher/call-taker or automatically by the CAEM 146.

The user interface 1102 of the CAP system 144 may be further configuredto display additional information about the emergency event 102, such asa name of the caller (e.g., retrieved according to the ANI/ALI system136 or a predetermined information supplemented according to a rule), aphone number of the caller, an address or location of the caller (e.g.,retrieved according to ALI or GPS), as well as supplementary details ofthe emergency event 102, such as additional caller information retrievedfrom an ACI database 138 in communication with an ACI server 140.

The user interface 1102 may accordingly be used to provide an overallstatus of the emergency events 102 being handled by the CAD system 112.The combination of the user interface 1102 of the CAP system and the CADsystem 112 may enable dispatch centers to respond to emergency requestsin the most expeditious manner. For example, the user interface 1102 mayallow a dispatcher to identify a set of multiple reported emergenciesthat all relate to a single underlying incident based on the displayedinformation. Accordingly the user interface 1102 information of the CAPsystem may reduce response time and increase the operational efficiencyof each dispatch center.

FIG. 12 illustrates an exemplary process 1200 for receiving andprocessing an emergency event 102 according to an identified eventpriority 104 and event type 106. The process 1200 may be performed byvarious devices, such as by the CAP system 144 in communication with oneor more event reporters over a communications network 120.

In block 1205, the CAP system 144 receives an emergency event 102. Theemergency event may include an event priority 104 and an event type 106.The event reporter may include reporters such as a smartphone 116executing an EPD application 118, and may be generated by userinteraction with a user interface of the EPD application 118 such asdescribed above. The event reporter may also include a phone device 122,a burglar alarm 124, a fire alarm 126, a car alarm 128, a medical alertdevice 130, a telematics unit 132, or a video feed 134. In some cases,the emergency event 102 may be generated automatically based on theemergency event 102 being detected by the event reporter, such as thefire alarm 126 detecting a fire and sending an emergency event 102 withan event priority 104 of high and an event type 106 of fire emergency.In some cases, while waiting for a connection to be established betweenthe event reporter and the CAP system 144 (such as via CAMA), the EPDapplication 118 may prompt the caller for one or more of event priority104 and event type 106 to include in the emergency event 102.

In block 1210, the CAP system 144 supplements the emergency event 102information. For example, the supplementation of the emergency event 102may be performed according to one or more of the data flows 200-A and200-B discussed in detail above with respect to FIGS. 2A and 2B.

In block 1215, the CAP system 144 identifies the event priority 104 andthe event type 106 of the emergency event 102. This identification maybe performed without querying the event reporter for additional eventpriority 104 and event type 106 information. Rather, the event priority104 and the event type 106 information may be identified from theemergency event 102.

In block 1220, the CAP system 144 determines based on the emergencyevent 102, whether the emergency event 102 indicates a higher eventpriority 104 emergency event 102 to be handled by the CAD system 112 ora lower priority emergency event 102 to be handled automatically by theCAEM 146. If the emergency event 102 is determined to be of a higherevent priority 104, control passes to block 1225. Otherwise, controlpasses to block 1235.

In block 1225, the CAP system 144 routes the emergency event 102 to theCAD system 112 for processing. Accordingly, the CAD system 112 may beconfigured to handle higher-priority emergency event 102 by way of adispatcher/call-taker at the CAD system 112.

In block 1230, the CAP system 144 provides the emergency event 102information to the dispatcher/call-taker. For example, the CAD system112 may establish a communications session between adispatcher/call-taker of the CAD system 112 and the reporting device(e.g., the smartphone 116 executing the EPD application 118), and mayfacilitate handling of the emergency event 102 via thedispatcher/call-taker. Rather than having to retrieve the event priority104 and event type 106 from the caller, the dispatcher/call-taker mayinstead have the easier task of confirming the information alreadyprovided by the emergency event 102, and of receiving any additionalinformation from the caller.

In block 1235 the CAP system 144 routes the emergency event 102 to theCAEM 146 for processing. Accordingly, the CAEM 146 may be configured toautomatically handle lower-priority emergency event 102, withoutrequiring the use of a dispatcher/call-taker at the CAD system 112.

In block 1240, the CAEM 146 automatically responds to the emergencyevent 102. For example, the CAEM 146 may be configured to return amessage to the user indicating that the emergency event 102 was receivedand will be processed. The CAEM 146 may also be configured to requestadditional information from the reporter of the emergency event 102.

In block 1245, the CAP system 144 updates the dispatch user interface.For example, emergency event 102 information in a display such as theuser interface 1102 may be updated with the current status of theemergency event 102 being handled. After block 1245 the process 1200ends.

With regard to the processes, systems, methods, heuristics, etc.described herein, it should be understood that, although the steps ofsuch processes, etc. have been described as occurring according to acertain ordered sequence, such processes could be practiced with thedescribed steps performed in an order other than the order describedherein. It further should be understood that certain steps could beperformed simultaneously, that other steps could be added, or thatcertain steps described herein could be omitted. In other words, thedescriptions of processes herein are provided for the purpose ofillustrating certain embodiments, and should in no way be construed soas to limit the claims.

In general, computing systems and/or devices, such as smartphone 116,may employ any of a number of computer operating systems, including, butby no means limited to, versions and/or varieties of the MicrosoftWindows® operating system, the Unix operating system (e.g., the Solaris®operating system distributed by Oracle Corporation of Redwood Shores,Calif.), the AIX UNIX operating system distributed by InternationalBusiness Machines of Armonk, N.Y., the Linux operating system, the MacOS X and iOS operating systems distributed by Apple Inc. of Cupertino,Calif., the BlackBerry OS distributed by Research In Motion of Waterloo,Canada, and the Android operating system developed by the Open HandsetAlliance.

Computing devices such as smartphone 116 generally includecomputer-executable instructions, where the instructions may beexecutable by one or more computing devices such as those listed above.Computer-executable instructions may be compiled or interpreted fromcomputer programs created using a variety of programming languagesand/or technologies, including, without limitation, and either alone orin combination, Java™, C, C++, Visual Basic, Java Script, Perl, etc. Ingeneral, a processor or microprocessor receives instructions, e.g., froma memory, a computer-readable medium, etc., and executes theseinstructions, thereby performing one or more processes, including one ormore of the processes described herein. Such instructions and other datamay be stored and transmitted using a variety of computer-readablemedia.

A computer-readable medium (also referred to as a processor-readablemedium) includes any non-transitory (e.g., tangible) medium thatparticipates in providing data (e.g., instructions) that may be read bya computer (e.g., by a processor of a computer). Such a medium may takemany forms, including, but not limited to, non-volatile media andvolatile media. Non-volatile media may include, for example, optical ormagnetic disks and other persistent memory. Volatile media may include,for example, dynamic random access memory (DRAM), which typicallyconstitutes a main memory. Such instructions may be transmitted by oneor more transmission media, including coaxial cables, copper wire andfiber optics, including the wires that comprise a system bus coupled toa processor of a computer. Common forms of computer-readable mediainclude, for example, a floppy disk, a flexible disk, hard disk,magnetic tape, any other magnetic medium, a CD-ROM, DVD, any otheroptical medium, punch cards, paper tape, any other physical medium withpatterns of holes, a RAM, a PROM, an EPROM, a FLASH-EEPROM, any othermemory chip or cartridge, or any other medium from which a computer canread.

Databases, data repositories or other data stores described herein mayinclude various kinds of mechanisms for storing, accessing, andretrieving various kinds of data, including a hierarchical database, aset of files in a file system, an application database in a proprietaryformat, a relational database management system (RDBMS), etc. Each suchdata store is generally included within a computing device employing acomputer operating system such as one of those mentioned above, and areaccessed via a network in any one or more of a variety of manners. Afile system may be accessible from a computer operating system, and mayinclude files stored in various formats. An RDBMS generally employs theStructured Query Language (SQL) in addition to a language for creating,storing, editing, and executing stored procedures, such as the PL/SQLlanguage mentioned above.

In some examples, system elements may be implemented ascomputer-readable instructions (e.g., software) on one or more computingdevices (e.g., servers, personal computers, etc.), stored on computerreadable media associated therewith (e.g., disks, memories, etc.). Acomputer program product may comprise such instructions stored oncomputer readable media for carrying out the functions described herein.The EPD application 118 may be one such computer program product. Insome example, the EPD application 118 may be provided as software thatwhen executed by the processor provides the operations described herein.Alternatively, the EPD application 118 may be provided as hardware orfirmware, or combinations of software, hardware and/or firmware.

Accordingly, it is to be understood that the above description isintended to be illustrative and not restrictive. Many embodiments andapplications other than the examples provided would be apparent uponreading the above description. The scope should be determined, not withreference to the above description, but should instead be determinedwith reference to the appended claims, along with the full scope ofequivalents to which such claims are entitled. It is anticipated andintended that future developments will occur in the technologiesdiscussed herein, and that the disclosed systems and methods will beincorporated into such future embodiments. In sum, it should beunderstood that the application is capable of modification andvariation.

All terms used in the claims are intended to be given their broadestreasonable constructions and their ordinary meanings as understood bythose knowledgeable in the technologies described herein unless anexplicit indication to the contrary in made herein. In particular, useof the singular articles such as “a,” “the,” “said,” etc. should be readto recite one or more of the indicated elements unless a claim recitesan explicit limitation to the contrary.

The Abstract of the Disclosure is provided to allow the reader toquickly ascertain the nature of the technical disclosure. It issubmitted with the understanding that it will not be used to interpretor limit the scope or meaning of the claims. In addition, in theforegoing Detailed Description, it can be seen that various features aregrouped together in various embodiments for the purpose of streamliningthe disclosure. This method of disclosure is not to be interpreted asreflecting an intention that the claimed embodiments require morefeatures than are expressly recited in each claim. Rather, as thefollowing claims reflect, inventive subject matter lies in less than allfeatures of a single disclosed embodiment. Thus the following claims arehereby incorporated into the Detailed Description, with each claimstanding on its own as a separately claimed subject matter.

What is claimed is:
 1. A system, comprising: a computer aidedprioritization (CAP) system in communication with a computer aideddispatch (CAD) system, a computer aided event module (CAEM), and anemergency event reporter device, the CAP system configured to: receive,from the emergency event reporter device, an emergency event including apriority selected from a set of event priorities; determine, based onthe emergency event and without querying the emergency event reporterdevice for additional information, whether the emergency event indicatesa higher priority emergency event to be handled by the CAD system or alower priority emergency event to be handled automatically by the CAEM;and selectively route the emergency event report to at least one of thecomputer aided dispatch (CAD) system and the computer aided event module(CAEM) according to the determination, wherein the computer aidedprioritization (CAP) system further configured to: receive an indicationthat the emergency event reporter device has changed location; andidentify an updated location reporter of the emergency event reporterdevice responsive to the indication that the emergency event reporterdevice has changed location.
 2. The system of claim 1, the emergencyevent including a type of event selected from a set of event typesassociated with the selected event priority, the computer aidedprioritization (CAP) system further configured to supplement informationincluded in the emergency event according to a predetermined rule forincluding additional information based at least in part on the type ofevent.
 3. The system of claim 2, the computer aided prioritization (CAP)system further configured to present the selected event priority, thetype of event, and the additional information to the dispatcherassociated with the computer aided dispatch (CAD) system before acommunications session is established between a dispatcher of the CADsystem and the emergency event reporter device.
 4. The system of claim2, the predetermined rule for including additional information in theemergency event report including at least one of: (i) a rule makingpre-entered emergency information available based on at least one of theselected event priority and the type of event; (ii) a rule includingtelematics data in the emergency event report for events including avehicle; (iii) a rule including health information in the emergencyevent report for events requiring medical attention; (iv) a ruleincluding additional contact information in the emergency event reportfor events requiring notification of emergency contacts; (v) a ruleincluding floor-plan information for events requiring access to abuilding; (vi) a rule including picture or video information for eventsfor which picture or video information is available; and (vii) a ruleincluding vehicle information for events that involve vehicles.
 5. Thesystem of claim 4, the computer aided prioritization (CAP) systemfurther configured to store the pre-entered emergency information on atleast one of the emergency event reporter devices and a remote databasein communication with the computer aided prioritization (CAP) system. 6.The system of claim 1, the computer aided prioritization (CAP) systemfurther configured to: present information associated with a pluralityof emergency event reports in a graphical user interface, each eventbeing identified at least according to the selected event priority andthe type of event; and indicate in the graphical user interface whichevents are being handled by a dispatcher associated with the CAP system,and which events are being handled by the computer aided event module(CAEM).
 7. The system of claim 1, the computer aided prioritization(CAP) system further configured to receive at least one of automaticnumber identification (ANI) and automatic location information (ALI). 8.The system of claim 7, the computer aided prioritization (CAP) systemfurther configured to supplement information included in the eventreport with additional information identified as associated with theevent report based on at least one of the automatic numberidentification (ANI) and the automatic location information (ALI). 9.The system of claim 7, the computer aided prioritization (CAP) systemfurther configured to present the selected event priority and the typeof event to a dispatcher associated with the computer aided dispatch(CAD) system accompanied by at least one of the automatic numberidentification (ANI) and the automatic location information (ALI). 10.The system of claim 1, the computer aided prioritization (CAP) systemfurther configured to: determine whether additional information wasincluded in the emergency event as submitted; if the additionalinformation was included in the emergency event, route the emergencyevent without additional supplementation; and if the additionalinformation was not included in the emergency event, supplement theinformation in the emergency event.
 11. The system of claim 1, the setof event priorities including at least two of a high priority eventindicative of a life-threatening event requiring urgent assistance, amedium priority event indicative of a non-life threatening eventrequiring urgent assistance, and a low priority event indicative of anon-life threatening event not requiring urgent assistance.
 12. Thesystem of claim 1, the set of event priorities including at least one ofa third party priority event indicative of a report of information wherea user of the emergency event reporter device is not involved, and ananonymous event priority indicative of a report of information where theuser of the emergency event reporter device is not involved and wishesto remain anonymous.
 13. The system of claim 1, the computer aidedprioritization (CAP) system further configured to: determine whether theemergency event reporter device is configured to support textualcommunication with a dispatcher associated with the emergency dispatchsystem; and enable textual communication with the dispatcher associatedwith the computer aided dispatch (CAD) system according to thedetermination.
 14. The system of claim 1, further comprising athird-party event interface in communication with the CAP system,wherein the emergency event is submitted via the third-party interface.15. A method, comprising: receiving, by a computer aided prioritization(CAP) system from an emergency event reporter device, an emergency eventincluding a priority selected from a set of event priorities, the CAPsystem in communication with a computer aided dispatch (CAD) system, acomputer aided event module (CAEM), and the emergency event reporterdevice; determining, based on the emergency event and without queryingthe emergency event reporter device for additional information, whetherthe emergency event indicates a higher priority emergency event to behandled by the CAD system or a lower priority emergency event to behandled automatically by the CAEM; and selectively routing the emergencyevent report to at least one of the computer aided dispatch (CAD) systemand the computer aided event module (CAEM) according to thedetermination, wherein the computer aided prioritization (CAP) systemfurther configured to: receive an indication that the emergency eventreporter device has changed location; and identify an updated locationreporter of the emergency event reporter device responsive to theindication that the emergency event reporter device has changedlocation.
 16. The method of claim 15, the emergency event including atype of event selected from a set of event types associated with theselected event priority, and further comprising supplementinginformation included in the emergency event by the computer aidedprioritization (CAP) system according to a predetermined rule forincluding additional information based at least in part on the type ofevent.
 17. The method of claim 16, further comprising presenting, by thecomputer aided prioritization (CAP) system, the selected event priority,the type of event, and the additional information to the dispatcherassociated with the computer aided dispatch (CAD) system before acommunications session is established between a dispatcher of thecomputer aided dispatch (CAD) system and the emergency event reporterdevice.
 18. The method of claim 16, the predetermined rule for includingadditional information in the emergency event report including at leastone of: (i) a rule making pre-entered emergency information availablebased on at least one of the selected event priority and the type ofevent; (ii) a rule including telematics data in the emergency eventreport for events including a vehicle; (iii) a rule including healthinformation in the emergency event report for events requiring medicalattention; (iv) a rule including additional contact information in theemergency event report for events requiring notification of emergencycontacts; (v) a rule including floor-plan information for eventsrequiring access to a building; (vi) a rule including picture or videoinformation for events for which picture or video information isavailable; and (vii) a rule including vehicle information for eventsthat involve vehicles.
 19. The method of claim 15, further comprising:presenting information associated with a plurality of emergency eventreports in a graphical user interface, each event being identified atleast according to the selected event priority and the type of event;and indicating in the graphical user interface which events are beinghandled by a dispatcher associated with the computer aidedprioritization (CAP) system, and which events are being handled by thecomputer aided event module (CAEM).
 20. The method of claim 15, furthercomprising storing pre-entered emergency information on at least one ofthe emergency event reporter devices and a remote database incommunication with the computer aided prioritization (CAP) system. 21.The method of claim 15, further comprising: receiving at least one ofautomatic number identification (ANI) and automatic location information(ALI); and supplementing information included in the event report withthe additional information identified as associated with the eventreport based on at least one of the ANI and the ALI.
 22. The method ofclaim 15, the set of event priorities including at least two of a highpriority event indicative of a life-threatening event requiring urgentassistance, a medium priority event indicative of a non-life threateningevent requiring urgent assistance, and a low priority event indicativeof a non-life threatening event not requiring urgent assistance.
 23. Themethod of claim 15, the set of event priorities including at least oneof a third party priority event indicative of a report of informationwhere a user of the emergency event reporter device is not involved, andan anonymous event priority indicative of a report of information wherethe user of the emergency event reporter device is not involved andwishes to remain anonymous.
 24. A non-transitory computer readablemedium storing an application software program, the application beingexecutable to provide operations comprising: receiving, by a computeraided prioritization (CAP) system from an emergency event reporterdevice, an emergency event including a priority selected from a set ofevent priorities and a type of event selected from a set of event typesassociated with the selected event priority, the CAP system incommunication with a computer aided dispatch (CAD) system, a computeraided event module (CAEM), and the emergency event reporter device;supplementing information included in the emergency event by the CAPsystem according to a predetermined rule for including additionalinformation based at least in part on the type of event; determining,based on the emergency event and without querying the emergency eventreporter device for additional information, whether the emergency eventindicates a higher priority emergency event to be handled by the CADsystem or a lower priority emergency event to be handled automaticallyby the CAEM; and selectively routing the emergency event report to atleast one of the computer aided dispatch (CAD) system and the computeraided event module (CAEM) according to the determination, wherein thecomputer aided prioritization (CAP) system further configured to:receive an indication that the emergency event reporter device haschanged location; and identify an updated location reporter of theemergency event reporter device responsive to the indication that theemergency event reporter device has changed location.